1. Field of the Invention
The present invention generally relates to name transformation for a Public Key Infrastructure (PKI). Specifically, the present invention provides a way to transform a directory name or the like into a name suitable for a PKI certificate.
2. Related Art
A Public Key Infrastructure (PKI) enables users of a basically unsecured public network such as the Internet to securely and privately exchange data through the use of a public and a private cryptographic key pair that is obtained and shared through a trusted authority. The PKI provides for a digital “certificate” that can identify an individual or an organization and directory services that can store and, when necessary, revoke the certificates.
The PKI assumes the use of public key cryptography, which is the most common method on the Internet for authenticating a message sender or encrypting a message. Traditional cryptography has usually involved the creation and sharing of a secret key for the encryption and decryption of messages. This secret key system has the significant flaw that if the key is discovered or intercepted by someone else, messages can easily be decrypted. For this reason, public key cryptography and the PKI is the preferred approach on the Internet. (The secret key system is sometimes known as symmetric cryptography and the public key system as asymmetric cryptography). In general, a PKI includes: (1) a certificate authority (CA) that issues and verifies digital certificate. A certificate generally includes the public key or information about the public key; (2) a registration authority (RA) that acts as the verifier for the certificate authority before a digital certificate is issued to a requestor; (3) one or more directories where the certificates (with their public keys) are stored; and (4) a certificate management system. The precise workings of how public and private key cryptography are well known to those of ordinary skill in the art and will not be restated herein.
As useful as PKI technology is, it is not without its drawbacks. For example, within an organization, individuals' contact information is frequently stored in a directory (e.g., an Lightweight Directory Access Protocol (LDAP) directory). Public key certificates are often stored in the same directory, in support of applications such as secure email. However, the directory names associated with individuals are often not well suited for use in certificates since directory names tend to be locally significant, often including intra-organizational information such as department, employee serial number, etc. As such, this information is often not suitable for externally-visible names. In addition, the use of X.509 certificates imposes additional restrictions on the contents of names that appear in certificates (e.g., they must be valid X.500 names, and for maximum interoperability should contain only well-known common naming attributes). Therefore, a user's directory name is often not suitable for use as a name that would appear in the user's certificate.
Verisign has a mechanism to address this problem in their CA that requires that names be broken-down into their component parts by the requestor, and sent to the Verisign CA. Upon receipt, the Verisign CA re-assembles them in an appropriate order to form a (CA-chosen) name. Unfortunately, this mechanism does not support the use of industry-standard certificate request structures (e.g. PKCS#10 and/or PKIX Certificate Template) for specifying the name, and is not suitable for sites that wish to use CAs from multiple vendors. Most other CAs require that the requester construct an appropriate PKI name prior to submitting a request.
In view of the foregoing, there exists a need for a system that is capable of providing a name for a PKI certificate that complies with any rules and/or restrictions. Specifically a need exists for a system that can transform a name of a directory or the like for a certificate requestor into a compliant name that can be used in the certificate.